Skip to main content
Expert Talk
Amakomaya — Aamako Maya Apps Pvt. Ltd.

Consent and Trust

Consent is where health architecture meets law and legitimacy. It is also where technically excellent exchanges stop, because the question "on what basis are you sharing this?" has no engineering answer.

Two things are worth separating at the outset:

  • Legal basis — why sharing is lawful at all. In many jurisdictions the basis for direct care is public interest or the provision of health care, not consent. Consent is one legal basis among several.
  • Consent — the individual's expressed choice about their data.

Building a consent service when the legal framework does not require consent for direct care produces a system that blocks care. Building none when the law requires it produces an unlawful exchange. Establish which applies, per data flow, before designing.

ModelHow it worksSuitsCost
Opt-in (explicit)Nothing shared until the person agreesHigh-sensitivity data; research; secondary useLow participation; the record is incomplete precisely for people who move between providers
Opt-outShared by default; the person may withdrawDirect care within a national system, where the law supports itRequires genuine public awareness or it is consent in name only
Granular / purpose-basedChoices per data category, per recipient type, per purposeMature systems with real patient engagementComplex to present, complex to enforce, easy to make unusable
Patient-mediatedThe person holds or authorises access directly, via an app or a carried summaryCross-border care, mobile populations, low institutional trustExcludes people without devices; incomplete by design
No consent (legal basis)Sharing is mandated or permitted by law — notifiable diseases, vital registrationPublic health surveillance, mandatory reportingMust be narrowly and clearly bounded, or it swallows everything

Most national systems end up with a layered model: no-consent for legally mandated flows, opt-out for direct care, opt-in for research and commercial secondary use. State which applies to which flow, in writing.

Purpose of use​

The same person, the same data, the same requester — but a different purpose — can be a different answer. This is the concept that makes consent enforceable rather than binary.

Common purposes: treatment, emergency treatment, payment, healthcare operations, public health, research, legal, patient request.

Design requirements:

  • The requester asserts the purpose with the request. This is a claim, not a proof — which is why it must be recorded in the audit log and be auditable after the fact.
  • Policy evaluates it against consent and law.
  • Misuse is detected retrospectively. A clinician who asserts "emergency treatment" fifty times a month is the pattern the audit log exists to find.

FHIR carries this in AuditEvent.purposeOfEvent and in security labels.

Break-glass​

Emergency override: a clinician accesses restricted data because the patient is unconscious and the alternative is harm.

The design rule is that break-glass is always available and never quiet:

  1. The clinician must actively invoke it and give a reason — a free-text reason is acceptable; a dropdown alone is not
  2. Access is granted immediately — no approval workflow, because the scenario is an emergency
  3. The event is logged with high visibility and flagged for review
  4. The patient is notified where the law and the clinical situation permit
  5. Every invocation is reviewed by a named function, and the rate is reported

A break-glass mechanism that is never reviewed becomes the normal access path within months. The review is the control; the button is just a button.

Provenance​

Consent decisions are only meaningful if you can say where data came from and who asserted it.

FHIR Provenance records the agent, the activity, the time and the entities involved. Practically, every clinical record in a shared repository should carry:

  • Which system supplied it
  • Which health worker asserted it (health worker registry identifier)
  • When it was recorded, distinct from when the event occurred
  • Whether it is an original assertion, a copy, a transformation, or a patient-reported statement

The last distinction matters clinically. A medication list copied forward through four systems and a medication list confirmed by a pharmacist look identical without provenance, and clinicians treat them very differently when they can tell them apart.

Security labels​

FHIR supports labels on resources — restricted, very restricted, normal — and handling instructions such as "do not redisclose". These express sensitivity at the resource level, which is what makes category-based consent possible.

The hard part is applying them consistently. Data does not arrive labelled; a system must decide that a particular observation relates to a sensitive category. Approaches — terminology-driven labelling (codes within a defined value set are labelled), source-driven (everything from a specified clinic), and clinician-applied — all have failure modes. Terminology-driven is the most maintainable and depends on the value sets being right, which brings this back to terminology governance.

Sensitivity is contextual. A pregnancy test result is unremarkable in most contexts and dangerous in some. An architecture that treats sensitivity as a fixed property of a code will get individual cases wrong; the patient-controlled restriction path is the mitigation.

Consent implemented inside each application produces divergent behaviour and unverifiable claims. It belongs in one service that others consult.

   Access request (who, what, why)
             │
             ▼
   ┌────────────────────┐        ┌─────────────────────┐
   │ Policy decision    │───────▶│ Consent service     │
   │ point              │◀───────│  FHIR Consent       │
   └─────────┬──────────┘        │  per patient        │
             │                   └─────────────────────┘
      permit │ deny                        ▲
             ▼                             │ record / withdraw
        Resource                    patient portal, registration
             │                      desk, CHW, call centre
             ▼
        Audit event

Requirements that are usually missed:

  • Withdrawal must work, and must be as easy as granting. Its effect on data already disclosed must be stated honestly to the patient — you cannot recall what another provider has already seen and copied.
  • Consent has a history. Which consent was in force at the time of an access must be reconstructible, or the audit log cannot be evaluated.
  • Multiple capture channels. Patients will not all use a portal. Registration desks, community health workers and call centres need a route.
  • Comprehensibility. Consent obtained through a screen nobody reads is not informed consent, whatever the record says.
  • Availability. If the consent service is down, what happens? Failing open discloses data the patient may have restricted; failing closed blocks care. This is a policy decision that must be made in advance, probably differing by purpose of use.

FHIR resource: https://hl7.org/fhir/consent.html

Trust frameworks​

Between organisations, technical controls are not enough. A trust framework is the set of rules participants agree to:

  • Eligibility — who may join, and what they must demonstrate
  • Technical conformance — standards, versions, testing, certification
  • Security obligations — controls, incident reporting timelines, audit rights
  • Identity assurance levels — how strongly each participant authenticates its users, and whether others must accept that
  • Permitted purposes — what data may be used for, and explicit prohibitions
  • Liability — who is responsible when something goes wrong
  • Enforcement — suspension and removal, and who decides
  • Change process — how the rules are amended

Without enforcement, a trust framework is a document. The credible ones tie participation to something participants need — reimbursement, licensing, or access to the exchange itself.

See governance.

Data minimisation​

The most reliable privacy control is not collecting or not disclosing data. Concretely:

  • Return the resources asked for, not $everything
  • Prefer id-only subscription payloads, so the notification channel carries no clinical data
  • Scope bulk exports to a Group, with a stated purpose and retention period
  • De-identify for analytics, deliberately — see health data
  • Set retention periods and actually delete

References​

Last updated on